1. Technical Field
The present invention relates to improvement of request shipping in distributed applications, particularly in workflow management systems, further referred to as WFMSs that are operating in a distributed environment in a networked computer system. In particular, the present invention relates to method and system for optimizing request shipping in such systems.
2. Prior Art
Although the subject matter of the invention is applicable to a broad variety of applications, i.e. whenever an application is able to be described with the basic structure and terminology of WFMSs, the present invention will be disclosed herein applied to WFMSs by way of example.
A new area of technology with increasing importance is the domain of WFMSs. WFMSs as for example implemented by IBM FlowMark support the modeling and execution of business processes. Business processes control which piece of work of a network of pieces of work will be performed by whom and which resources are exploited for this work, i.e. a business process describes how an enterprise will achieve its business goals. The individual pieces of work might be distributed across a multitude of different computer systems connected by some type of network.
The process of designing, developing and manufacturing a new product and the process of changing or adapting an existing product presents many challenges to product managers and engineers to bring the product to market for the least cost and within schedule while maintaining or even increasing product quality. Many companies are realizing that the conventional product design process is not satisfactory to meet these needs. They require early involvement of manufacturing engineering, cost engineering, logistic planning, procurement, manufacturing, service and support with the design effort. Furthermore, they require planning and control of product data through design, release, and manufacturing.
The correct and efficient execution of business processes within a company, e.g. development or production processes, is of enormous importance for a company and has significant influence on company""s overall success in the market place. Therefore, those processes have to be regarded similar as technology processes and have to be tested, optimized and monitored. The management of such processes is usually performed and supported by a computer based process or WFMS.
In D. J. Spoon: xe2x80x9cProject Management Environmentxe2x80x9d, IBM Technical Disclosure Bulletin, Vol. 32, No. 9A, February 1990, pages 250 to 254, a process management environment is described including an operating environment, data elements, and application functions and processes.
In R. T. Marshak: xe2x80x9cIBM""s FlowMark, Object-Oriented Workflow for Mission-Critical Applicationsxe2x80x9d, Workgroup Computing Report (USA), Vol. 17, No. 5, 1994, page 3 to 13, the object character of IBM FlowMark as a client/server product built on a true object model that is targeted for mission-critical production process application development and deployment is described. In H. A. Inniss and J. H. Sheridan: xe2x80x9cWorkflow Management Based on an Object-Oriented Paradigmxe2x80x9d, IBM Technical Disclosure Bulletin, Vol. 37, No. 3, March 1994, page 185, other aspects of object-oriented modeling on customization and changes are described.
In F. Leymann and D. Roller: xe2x80x9cBusiness Process Management with FlowMarkxe2x80x9d, Digest of papers, Cat. No. 94CH3414-0, Spring COMPCON 94, 1994, pages 230 to 234, the state-of-the-art computer process management tool IBM FlowMark is described. The meta model of IBM FlowMark is presented as well as the implementation of IBM FlowMark. The possibilities of IBM FlowMark for modeling of business processes as well as their execution are discussed. The product IBM FlowMark is available for different computer platforms and documentation for IBM FlowMark is available in every IBM branch.
In F. Leymann: xe2x80x9cA meta model to support the modeling and execution of processesxe2x80x9d, Proceedings of the 11th European Meeting on Cybernetics and System Research EMCR92, Vienna, Austria, Apr. 21 to 24, 1992, World Scientific 1992, pages 287 to 294, a meta model for controlling business processes is presented and discussed in detail.
The xe2x80x9cIBM FlowMark for OS/2xe2x80x9d, document number GH 19-8215-01, IBM Corporation, 1994, available in every IBM sales office, represents a typical modern, sophisticated, and powerful WFMS. It supports the modeling of business processes as a network of activities; refer for instance to xe2x80x9cModeling Workflowxe2x80x9d, document number SH 19-8241, IBM Corporation, 1996. As further information on Workflow Management Systems available in IBM sales offices one could mention: IBM MQSeries Concepts and Architecture, document number GH 12-6285; IBM MQSeries Getting Started with Buildtime, document number SH 12-6286; IBM MQSeries Getting Started with Runtime, document number SH 12-6287. This network of activities, the process model, is constructed as a directed, acyclic, weighted, colored graph. The nodes of the graph represent the activities or workitems which are performed. The edges of the graph, the control connectors, describe the potential sequence of execution of the activities. Definition of the process graph is via the IBM FlowMark Definition Language (FDL) or the built-in graphical editor. The runtime component of the workflow manager interprets the process graph and distributes the execution of activities to the right person at the right place, e.g. by assigning tasks to a work list according to the respective person, wherein said work list is stored as digital data within said workflow or process management computer system.
In F. Leymann and W. Altenhuber: xe2x80x9cManaging business processes as an information resourcexe2x80x9d, IBM Systems Journal, Vol. 32(2), 1994, the mathematical theory underlying the IBM FlowMark product is described.
In D. Roller: xe2x80x9cVerifikation von Workflows in IBM FlowMarkxe2x80x9d, in J. Beckerund G. Vossen (Hrsg.): xe2x80x9cGeschaeftsprozessmodellierung und Workflowsxe2x80x9d, International Thompson Publishing, 1995, the requirement and possibility of the verification of workflows is described. Furthermore the feature of graphical animation for verification of the process logic is presented as it is implemented within the IBM FlowMark product.
For implementing a computer based process management system, firstly the business processes have to be analyzed and, as the result of this analysis, a process model has to be constructed as a network of activities corresponding to the business process. In the IBM FlowMark product, the process models are not transformed into an executable. At run time, an instance of the process is created from the process model, called a process instance. This process instance is then interpreted dynamically by the IBM FlowMark product.
A user typically interacts with the WFMS via a graphical end user interface that represents the tasks to be performed by the user as icons. Work for a particular task is started by the user by double-clicking on the appropriate icon which in turn starts the program implementing the activity.
Said activities are generally steps within a particular business process. Each activity represents a piece of work which the assigned person can complete by starting a program or another process.
The activities to be performed have typically a fine structure:
An Activation Condition defines when the activity is ready for scheduling by the workflow manager; an Exit Condition defines when an activity should be treated as complete by the workflow manager. The core of the activity is the Task which is comprised of the proper activity and a query on an organization database. The Proper Activity associates the activity with a program object. The program object defines for each operating system, and possibly for each user, the name and operational characteristics for an executable piece of software. The executable piece of software is started when the activity is performed by a user. The query on the organization database defines the persons responsible for performing the activity. When the activity is ready to be scheduled, the workflow management executes the specified query against the organization-database. This query returns a set of persons, to which the activity is assigned to. The task is transformed into a set of work items, one for each person selected as the result of the query against the organization database. The work item contains the name of the person and the program to be executed. These work items are made part of the users"" worklist.
Each of the activities is performed by an activity implementation. The activity implementations are typically programs, but they may also be the invocation of a method object or a stored procedure in a relational data base. This will be described later with reference to
FIG. 2. The results that are in general produced by the work represented by an activity is put into an output container, which is associated with each activity. Since an activity will in general require to access output containers of other activities, each activity is associated in addition with an input container too. At run time, the actual values for the formal parameters building the input container of an activity represent the actual context of an instance of the activity. Each data container is defined by a data structure. A data structure is an ordered list of variables, called members, that have a name and a data type. Data connectors represent the transfer of data from output containers to input containers. When a data connector joins an output container with an input container, and the data structures of the two containers match exactly, the FlowMark workflow manager maps the data automatically.
A business process model also encompasses the description of the flow of the activities itself between xe2x80x9cresourcesxe2x80x9d actually performing the pieces of work represented by each activity. A resource may be specified as a particular programxe2x80x9d person, a role, or an organizational unit. At run time tasks are resolved into requests to particular persons to perform particular activities resulting in work items for that person. Staff assignments are the means to distribute activities to the right people in the sequence prescribed by the control flow aspect of a business process model. The way how staff is assigned will be described in more detail later in chapter 4.1. Each activity in a process is assigned to one or more staff members defined in the FlowMark database. Whether an activity is started manually by the user or automatically by the FlowMark workflow manager, and whether it requires user interaction to complete or completes automatically, a staff member must be assigned to it. FlowMark staff definition entails more than identifying people at your enterprise to the FlowMark database. For each person defined, you can specify a level, an organization, and multiple roles. These attributes can be used at run time to dynamically assign activities to people with suitable attributes.
A base assumption of such prior art systems is that one specific WFMS is the owner of the workflow. For other workflows a different WFMS can be the workflow owner. The owner WFMS starts and controls the execution of the appropriate workflow. This WFMS is called the xe2x80x98localxe2x80x99 WFMS as this is the usual place for the workflow to execute.
A further base assumption is that a user is always assigned to only one WFMS for which the user is identified, for example, by his/her user ID.
If a user is selected for a certain activity and said user is assigned to another WFMS appropriate information must be shipped to said other WFMS to be able to handle that activity. This shipping of information is referred to in the following as xe2x80x98request shippingxe2x80x99. For obvious reasons, said other WFMS is called a xe2x80x98remotexe2x80x99 WFMS.
If only one user is selected, a respective work request including associated activity data can be shipped immediately to said other WFMS. Said activity data comprises the input container, the output container partly filled with default values, the staff specific data and the activity specific data.
In particular, the actions which are taken by the local WFMS when a user is selected who is assigned to a remote WFMS are summarized as follows:
First, staff resolution is performed which is described in more detail later in the introductory chapter 4.1. For simplicity, it is assumed that precisely one user is selected for working on the activity. If the only selected user is not part of the local WFMS the appropriate workflow system is determined. Next, a request is sent to the remote WFMS including said activity data. Then it is waited for response. When the response is obtained the local WFMS takes appropriate actions such as storing the output container in the database, storing the audit trail information and continuing navigation.
The remote WFMS takes the following actions:
It receives the request from the local WFMS. Then, said activity data is saved in a database. Next, a work item is created for the specified user and is put on this user""s worklist.
Then, the system has to wait until the user selects his work item. The containers must be retrieved from the data base and the activity implementation has to be invoked. Then the audit trail records are created, container requests are honored and the system has to wait until the activity implementation is completed.
Next, the container and the audit trail are sent back to the local WFMS and any residue is cleaned up.
A much more complex processing is required, when users of more than one WFMS are selected during staff resolution. In this case, it must be ensured that one and only one user executes the activity. This requires that the involved WFMS exchange further information beside the simple request shipping. As in the simple case, the local WFMS orchestrates all interactions between the affected WFMSs.
The following steps are executed in this case. For simplicity it is assumed that no user from the local WFMS has been selected.
The local WFMS sends a work item request to all remote WFMSs that host at least one selected user. The work item request contains a list of all users that are associated with the targeted WFMS, plus information that allows the remote WFMSs to create work items for the selected users. The remote WFMSs create work items for each user and insert those work items into the appropriate work lists of the users. As this is done by a remote WFMS those work items are considered as remote work items by the local WFMS.
When a user selects a work item, the appropriate WFMS first removes it from the worklist of all other users that are associated with the same WFMS and then informs the local WFMS that the work item has been selected.
The local WFMS determines the remote WFMS on which the activity was first selected and sends a xe2x80x98request for executionxe2x80x99 to the selected remote WFMS. This request contains all activity related information.
The local WFMS broadcasts to the other remote WFMSs that their requests are no longer honored. The non-selected WFMSs delete the work items from the respective worklists. In the case a user has already selected his work item, the user is informed that somebody else has selected the work item.
After the work item was finished by the selected user, the remote WFMS ships back the output container and the audit trail information.
The local WFMS stores the output container in it""s database, stores the audit trail information and continues navigation.
The problem underlying to the present invention thus consists in the large number of xe2x80x98distributedxe2x80x99 or xe2x80x98remotexe2x80x99 work items, because it is obvious from the previous description that management of distributed work items, i.e. shipping of work requests between different WFMSs is expensive. The costs associated with this type of processing are proportional to the number of WFMSs that need to be involved in the processing of an activity.
It is therefore the general object of the present invention to provide a method and system for optimizing request shipping in distributed applications and particularly in workflow management systems.
The present invention is directed to a method for optimizing request shipping within a plurality of distributed networked computer systems holding a distributed networked computer systems holding a distributed application the usage of which realizes a process model underlying said application is proposed in which said process model comprises a business process consisting of a plurality of activities to be performed on said application systems by a plurality of users, including shipping of activity requests between a local application system owning said business process and a plurality of remote application systems performing said activities with the help of a plurality of users.
The basic idea is to optimize the assignment of the users to the appropriate application system by re-assigning users to a different WFMS in such a way that the number of remote work item requests is optimized. The inventional method can be advantageously applied to workflow management systems (WFMSs). The optimization process involved comprises applying a so-called xe2x80x98optimization functionxe2x80x99 reflecting the overall costs for request shipping and additional costs for performing the business process.
Hereby, an essential parameter is the number of involved application systems, particularly of WFMSs, because they are the receivers of the xe2x80x98expensivexe2x80x99 work item requests shipped in the overall system. The second essential parameter is the number of work item requests shipped in the system.
Amongst others, further additional constraints influencing the costs are hardware costs, available bandwidth on data links between particular application systems, or WFMSs respectively, maintenance costs, and individual product quality costs specific for each business process and enterprise.
Thus, overall costs including all above mentioned parameters should be minimized by the inventional method within reasonable limits determined by the enterprise""s management.
For performing said optimization function an optimization data gathering step is required. In this step a plurality of facts are collected some facts being statistical data and some non-statistical data.
Then the individual optimization data are weighted and the overall optimization function can thus be established or an already existing function can be selected and applied, respectively. As a result of the optimization, users are possibly re-assigned to a different application system, particularly to a different WFMS. Thus, the number of work item requests will be reduced with the re-assignment.
The method of the present invention with the characteristics of claim 1 has the advantage, in relation to the method sketched out in the discussion of prior art technique that request shipping is lowered and thus the costs associated with performing the business process are lowered.
In a preferred embodiment of the inventional method the data gathering step comprises extracting the optimization data from the audit trail of the local WFMS.
In a preferred embodiment of the inventional method the number of WFMS is reduced by combining several WFMSs. Thus, request shipping and costs can be further reduced.